W-1 — uspAuthReadyProvider has no production consumer 🟢 High [both reviewers]

lib/providers/auth/usp_auth_ready_provider.dart:19

The provider is introduced as the "single source of truth" for USP auth readiness, but searching lib/ in the PR branch finds it consumed only within its own file and one explanatory comment in dashboard_orchestrator.dart (which explicitly bypasses it due to the staleness caveat). Neither the WiFi nor Internet settings notifier references it. If this is intentional future infrastructure, the PR description should say so.

Fix: Either note "reserved for follow-up" in the PR description, or wire it into the notifiers if the staleness caveat does not apply to those call sites.

W-2 & W-3 — performSave() has no RA-mode write guard 🟡 Medium [single reviewer A]

lib/page/internet_settings/providers/usp_internet_settings_notifier.dart:139
lib/page/wifi_settings/providers/usp_wifi_settings_provider.dart:174

Before this PR, the if (!usp.isAuthenticated) { throw ConnectivityError … } gate in performFetch() also prevented RA sessions from ever reaching edit state — so performSave() was unreachable in practice. Now that performFetch() succeeds in RA mode, a user can enter edit mode and trigger performSave(). Neither settings view wires up remoteAccessProvider.select(s => s.isRemoteReadOnly) (the recommended pattern from docs/plans/2026-01-20-remote-read-only-mode-usage.md), and USP SET calls go through the WASM client path — not through RouterRepository where JNAP write-blocking lives.

// usp_internet_settings_notifier.dart:139 (PR branch) — no RA guard
@override
Future<void> performSave() async {
  // proceeds directly to service.saveAll() via uspMutationLockProvider.withLock()
  await ref.read(uspMutationLockProvider).withLock(() async {
    await service.saveAll(state.original, state.edited, ...);
  });
}

Whether the backend enforces RA write restrictions on USP SET is not verifiable from source; the PR assumes server-side enforcement without a client-side safety net.

Fix: Add an RA guard to both performSave() implementations, e.g.:

final isRA = ref.read(authProvider).value?.isRemoteAssistance ?? false;
if (isRA) throw const UnexpectedError(detail: 'Write not allowed in RA mode');

Or wire up isRemoteReadOnly in the settings views to disable save controls in RA mode.

W-4 — loginType migration is partial in router_provider.dart 🟡 Medium [single reviewer B]

lib/route/router_provider.dart:162-164

The PR updates the Remote-build-mode RA guard (lines 143-145) to isRemoteAssistance, but the local-auth loginType reads on lines 162-164 remain. This is pre-existing and not a regression, but the migration described in the PR description ("canonical replacement") is incomplete.

Fix: Follow-up cleanup or note in PR description.

• Core fix is correct: usp.isAuthenticated is a WASM transport signal that stays false in RA mode by design; removing it from performFetch() unblocks #1119 without affecting local login paths.
• AuthState.isRemoteAssistance getter: Well-documented, correctly derived, replaces inline loginType == LoginType.remote in all the changed callsites (session guard, router redirect, dashboard orchestrator).
• uspAuthReadyProvider design logic: Sound; the staleness caveat is clearly documented. The deliberate bypass in dashboard_orchestrator (which calls restoreSession and observes the flag synchronously) is architecturally correct and well-commented.
• Test coverage: usp_auth_ready_provider_test.dart (5 cases), RA-bypass regression tests for both notifiers, isRemoteAssistance unit test, null-USP error path — all confirmed present in the PR branch and well-structured.
• uspMutationLockProvider.withLock() discipline preserved in both performSave() implementations.
• No hardcoded secrets or injection vectors found.

W-1 — performSave() no RA-mode write guard (Internet Settings) — High [both reviewers, prior — still unfixed]

lib/page/internet_settings/providers/usp_internet_settings_notifier.dart:135

Before this PR the if (!usp.isAuthenticated) gate in performFetch effectively blocked RA users from reaching edit state. Now that performFetch succeeds in RA mode, a user can enter edit mode and call performSave(). The notifier does not check isRemoteAssistance / isRemoteReadOnly before proceeding to service.saveAll(...). isRemoteReadOnly does not exist anywhere in the codebase.

Fix: Add an RA guard in performSave():

final isRA = ref.read(authProvider).value?.isRemoteAssistance ?? false;
if (isRA) throw const UnexpectedError(detail: 'Write not allowed in RA mode');

W-2 — performSave() no RA-mode write guard (Wi-Fi Settings) — High [both reviewers, prior — still unfixed]

lib/page/wifi_settings/providers/usp_wifi_settings_provider.dart:176

Same issue as W-1 for the Wi-Fi notifier. RA users can trigger saveQuickSetup/saveAdvanced via USP SET, changing router WiFi settings without local-admin authorization.

Fix: Same pattern — guard with isRemoteAssistance before issuing writes.

W-3 — uspAuthReadyProvider has zero production consumers — High [both reviewers, prior — still unfixed]

lib/providers/auth/usp_auth_ready_provider.dart:19

Global search confirms the only references to uspAuthReadyProvider are its definition and a comment in dashboard_orchestrator.dart explaining why not to use it. It is dead code.

Fix: Either wire it into the notifiers' fetch guards (replacing the removed isAuthenticated gate), or document clearly that it is "reserved for future use" and mark it accordingly.

W-4 — router_provider.dart:143-145 Remote-build-mode branch not migrated — High [both reviewers]

lib/route/router_provider.dart:143-145

// L143-145 (unchanged in PR)
final loginType =
    ref.read(authProvider.select((value) => value.value?.loginType));
if (loginType == LoginType.remote) {

The PR migrated L162-164 to isRemoteAssistance but left the Remote-build-mode branch at L143-145 on the raw loginType == LoginType.remote pattern. Semantically equivalent now, but defeats the stated goal of a canonical single check.

Fix: Migrate this callsite to isRemoteAssistance for consistency.

W-5 — uspAuthReadyProvider API design contradiction — High [both reviewers]

lib/providers/auth/usp_auth_ready_provider.dart:5-24

The provider is documented as "Single source of truth for USP auth readiness" yet its own docstring warns "read this at the decision point (ref.read)" because UspClient.isAuthenticated does not trigger Riverpod invalidation. The orchestrator comment at dashboard_orchestrator.dart:132 explicitly says it bypasses this provider for that reason. A provider that cannot be safely ref.watch-ed but is named as SSOT is a trap — future consumers who ref.watch it will get a stale cache on restoreSession.

Fix: Either (a) convert to an extension getter AuthState.isUspReady and remove the Provider wrapper; or (b) rename to uspLoginIntentProvider with clear scope docs that it only reflects loginType intent, not transport-layer state.

W-6 — RemoteAssistanceSessionGuard._checkAndRestoreSession has no test coverage — High [single reviewer B]

lib/page/remote_assistance/views/remote_assistance_session_guard.dart:63

if (ref.read(authProvider).value?.isRemoteAssistance ?? false) return;

This is the one migration in this PR that has no corresponding test. PR adds RA bypass tests for both notifiers and a full usp_auth_ready_provider_test.dart, but RemoteAssistanceSessionGuard has no test file at all. This callsite is the early-return guard preventing credential restore in RA mode — a regression here would be a correctness bug.

Fix: Add test/page/remote_assistance/views/remote_assistance_session_guard_test.dart covering: (1) RA mode → _checkAndRestoreSession returns early; (2) local mode → credential restore proceeds.

W-7 — uspWifiSettingsServiceProvider force-unwraps nullable uspClientProvider — Med [single reviewer A]

lib/page/wifi_settings/providers/usp_wifi_settings_provider.dart:17-18

final uspWifiSettingsServiceProvider = Provider<UspWifiSettingsService>(
  (ref) => UspWifiSettingsService(ref.read(uspClientProvider)!),  // force-unwrap
);

On non-Web platforms or before UspClient is registered in getIt, uspClientProvider returns null. The ! throws a bare Null check operator used on a null value — not a typed ServiceError — so the notifier's on ServiceError catch won't catch it. Compare with uspInternetSettingsServiceProvider which explicitly throws ServiceNotInitializedError.

Fix: Replace ! with an explicit null check:

(ref) {
  final usp = ref.read(uspClientProvider);
  if (usp == null) throw const ServiceNotInitializedError(detail: 'UspClient not available');
  return UspWifiSettingsService(usp);
}

W-8 — New provider missing barrel export — High [single reviewer B]

lib/providers/auth/_auth.dart:1-2

// _auth.dart (current)
//GENERATED BARREL FILE
export 'auth_provider.dart';

usp_auth_ready_provider.dart was added to the same lib/providers/auth/ directory but is not exported from the barrel file. Any future consumer following the barrel convention won't find it without knowing its exact path.

Fix: Add export 'usp_auth_ready_provider.dart'; to _auth.dart.

• Core fix is correct: removing usp.isAuthenticated gate from performFetch unblocks RA sessions without affecting local-login paths.
• AuthState.isRemoteAssistance getter: well-documented, correctly derived, used consistently in session_guard, router_provider, and dashboard_orchestrator.
• uspAuthReadyProvider logic: semantically correct; the staleness caveat is clearly documented. Dashboard orchestrator bypass is architecturally sound and well-commented.
• Test coverage (main paths): RA bypass regression tests for both notifiers, usp_auth_ready_provider_test.dart (5 cases), isRemoteAssistance unit test, null-USP error path — all well-structured.
• uspMutationLockProvider.withLock() discipline preserved in both performSave() implementations.
• No hardcoded secrets or injection vectors.

• W-4 FIXED ✓ — router_provider.dart:143-145 Remote-build-mode branch correctly migrated to isRemoteAssistance getter.
• W-5 FIXED ✓ — uspAuthReadyProvider API design contradiction resolved: usp_auth_ready_provider.dart now has full docstring explaining RA-mode staleness caveat; orchestrator bypass comment consistent.
• Core fix correct ✓ — Removing !usp.isAuthenticated gate from performFetch() in both Internet/WiFi notifiers is correct. The router guards routes; usp == null guard covers uninitialized case. Nine sibling providers never had this gate.
• W-7 (partial) ✓ — performFetch() now has usp == null null guard before reaching uspWifiSettingsServiceProvider, preventing the crash on the fetch path. (But performSave() still lacks this guard — see table.)
• isRemoteAssistance getter ✓ — Correctly derived, well-documented, used consistently in session_guard, router_provider:143, dashboard_orchestrator.

W-1 (prior, still open) — performSave() no RA-mode guard (Internet Settings) — 🟢High [both reviewers]

lib/page/internet_settings/providers/usp_internet_settings_notifier.dart:139-165

@override
Future<void> performSave() async {
  // ...no isRemoteAssistance check...
  // ...no usp == null check...
  try {
    final service = ref.read(uspInternetSettingsServiceProvider);
    await ref.read(uspMutationLockProvider).withLock(() async {
      await service.saveAll(...);   // ← proceeds in RA mode

RA user can enter edit mode (fetch now succeeds) and trigger a write that goes through to WASM/USP, changing WAN settings without local-admin authorization.

Fix:

if (ref.read(authProvider).value?.isRemoteAssistance ?? false) return;

Add at top of performSave() body.

W-2 (prior, still open) — performSave() no RA-mode guard + force-unwrap crash (Wi-Fi Settings) — 🟢High [both reviewers]

lib/page/wifi_settings/providers/usp_wifi_settings_provider.dart:174 + usp_wifi_settings_service.dart:18

// Service provider (usp_wifi_settings_service.dart:18) — UNCHANGED:
final uspWifiSettingsServiceProvider = Provider<UspWifiSettingsService>(
  (ref) => UspWifiSettingsService(ref.read(uspClientProvider)!),  // force-unwrap
);

// performSave() (usp_wifi_settings_provider.dart:174-199) — no guard:
@override
Future<void> performSave() async {
  try {
    await ref.read(uspMutationLockProvider).withLock(() async {
      await _svc.saveQuickSetup(...);   // ← _svc = ref.read(uspWifiSettingsServiceProvider)

_svc calls uspWifiSettingsServiceProvider which force-unwraps uspClientProvider!. If client is null at save time, this throws Null check operator used on a null value — an unhandled crash, not a typed ServiceError. performFetch() has a usp == null guard but performSave() does not.

Fix: (1) Replace ! in service provider with explicit null check (throw ServiceNotInitializedError). (2) Add isRemoteAssistance guard at top of performSave().

W-3 (prior, still open) — uspAuthReadyProvider zero production consumers — 🟢High [both reviewers]

lib/providers/auth/usp_auth_ready_provider.dart:19

Codebase search (lib/**/*.dart) returns zero import/usage hits for uspAuthReadyProvider outside its own file. The only code reference is dashboard_orchestrator.dart:132 — a comment explaining why NOT to use it. The provider is well-documented and tested but dead at runtime. Either wire it into performFetch paths (replacing their duplicated inline logic) or document as "reserved / future use."

W-6 (prior, still open) — _checkAndRestoreSession no test coverage — 🟢High [single reviewer B]

lib/page/remote_assistance/views/remote_assistance_session_guard.dart:63-75

Search of test/ returns zero results for any remote_assistance* test file. This is the sole migration callsite in this PR without a test. Covers three paths: RA-bypass early return, null-credentials early return, credential restore.

Fix: Add test/page/remote_assistance/views/remote_assistance_session_guard_test.dart covering at minimum the RA-bypass case.

W-7 (prior, still open) — uspWifiSettingsServiceProvider force-unwrap crash — 🟢High [single reviewer A]

lib/page/wifi_settings/services/usp_wifi_settings_service.dart:18

final uspWifiSettingsServiceProvider = Provider<UspWifiSettingsService>(
  (ref) => UspWifiSettingsService(ref.read(uspClientProvider)!),  // ← crash
);

Contrast with uspInternetSettingsServiceProvider (same file direction, different service) which throws ServiceNotInitializedError. The Wi-Fi service crashes with bare Null check operator — unhandled, not typed, bypasses on ServiceError catch.

Fix:

(ref) {
  final usp = ref.read(uspClientProvider);
  if (usp == null) throw const ServiceNotInitializedError(detail: 'UspClient not available');
  return UspWifiSettingsService(usp);
}

W-8 (prior, still open) — usp_auth_ready_provider.dart missing barrel export — 🟢High [single reviewer B]

lib/providers/auth/_auth.dart:2

//GENERATED BARREL FILE
export 'auth_provider.dart';
// ← usp_auth_ready_provider.dart not exported

Any future consumer following the barrel convention won't find it.

Fix: Add export 'usp_auth_ready_provider.dart'; to _auth.dart.

N-1 (new) — isLoggedIn getter promised by PR but absent from codebase — 🟢High [both reviewers]

lib/providers/auth/auth_state.dart

PR description and diff state bool get isLoggedIn => loginType != LoginType.none; was added. Actual disk inspection: isLoggedIn is absent from auth_state.dart. Codebase-wide grep returns zero matches. ~5 call sites remain on raw loginType comparisons:

• app.dart:236: loginType == null || loginType == LoginType.none
• root_container.dart:48: loginType == LoginType.none
• login_local_view.dart:110: loginType != null && loginType != LoginType.none
• usp_top_bar.dart:74: same pattern
• router_provider.dart:162-165: loginType == null || loginType == LoginType.none

Either commit the getter + consumer migrations, or scope them out explicitly with a follow-up ticket.

N-2 (new) — _tryResumeSse() raw loginType pattern — 🟢High [single reviewer A]

lib/app.dart:236

void _tryResumeSse() {
  final loginType = ref.read(authProvider).value?.loginType;
  if (loginType == null || loginType == LoginType.none) return;

This is one of the ~5 sites that should migrate to isLoggedIn per PR intent. Not a functional bug (semantically equivalent), but defeats the stated unification goal.